im pretty sure i wrote a response for this ticket but seems like i forgot to submit it..

anyway what i wanted to say is that the problem here is that we treat different command suffix in a wrong way. strings are usually determined by:

• 0 : null byte terminated
• z : zero terminated string
• s : string

it feels like p8s should be doing a string.. and this 'spaced' bytepairs seems confusing, so let me think a bit on all those subcommands a little and ill suggest more changes on the p8 subcommands as well as in px

Coming from #24791,

I was wondering what was the meaning of a TODO mentioning supporting pq0.

In my understanding, the prefix (pq in my case, p8 here) states the action to perform, i.e printing 8bit hexpair list of bytes. The suffix then acts as a "stopping condition".

So, following this logic, pq0 would mean printing data up to the next null byte, as a QRCode. Then I would expect the p8 command to do the same, which is printing hex bytes.

However, the p8 is using suffix to configure the output format. So the suffix should be treated differently for pq and p8 commands, or more generally, should be different for commands that will have a fixed output format and commands requiring a "stopping condition".

As changing p8s to print escaped hex strings like pcs, my take is: how would you print space-separated hex bytes, as p8s is currently doing? p8s looks the best candidate IMHO. I'd expect something like p8h or p8\ to print as escaped hex strings (like pcs is doing).

I don't know if reaching consistency across all printing commands with suffixes controlling the output format is possible TBH. As long as things are fairly logical/natural I think it's ok, and there will edge cases that will mess up our dream of perfect order.

This was my 2¢